I think this PR has some content that is cognitively very hard to review it because it has many other changes unrelated to the main point of the PR, which is just changing the default. On the other hand, I understand that's the nature of the problem being solved here. 😅

I understand that changing the default is going to have implications in the sense that you have to do many other changes so that the new default doesn't break anything. And I also understand creating a PR for each of those changes would be huge and extremely unnecessary overhead. I don't want to impose any of that. I don't think we should impose rules where PRs cannot propose things in passing because that would create a necessary overhead for this project, and considering the actual state of the project, that's unreasonable. Maybe just separating commits that are unrelated to the problem is quite reasonable and makes review much easier (even though the GitHub UI unfortunately doesn't let us know where the change comes from if we choose to review the whole PR). 🙂

But from the point of reviewing it, because everything is in a single commit, it's really hard to review it because there are so many small changes in boring parts of the code far from each other involving build script, CI, and everything else. Those parts are disconnected, and there's no rationale for them. Anyone reviewing it just has to reverse engineer the code to figure out what's happening there. Even then, the person will figure out what's happening there, but not why that was necessary. Maybe another solution is just being more generous with comments, I guess. In fact I implemented a feature where we can now include comments in the C++ actions variables that for multi-line inputs like the case of the extended matrix handlebars templates. 😀

To be clear, I have no idea what the best solution for this is. But it's worth thinking about it. I mean all of us 😀. Maybe the best solution is just creating lots of commits and in the end, when the PR is about to be merged, we aggregate the commits that represent the same kind of feature into a single commit. So that the PR has rationale for the changes and the final PR has necessary structure for what users will see. But I'm not sure about any of that. We just have to think about that.

For now, for the small things, I'll just trust you to be honest. So, I'll just try to comment on whatever seems problematic to me because (maybe ironically) the bigger changes are easier to understand. At some point, I realized that was leaving a lot of comments just asking what things do and why they were there. I went back through my review at the end, deleting those comments because they were too repetitive. 😆

Anyway, the PR is pretty good. With the exception of the question about Mr.Docs' flags not being static for GCC, I think all other comments are mostly about ideas for brainstorming. (I also didn't really review the codecov issue because I know you're already on it)

LGTM 👍